Check for _CountingAttr subclasses#1544
Conversation
|
While I'm always super open to expand our… expandability… this needs more meat for the motivation. Like concrete examples that it enables – which could go straight into, probably, expanding.md? In other words it seems a bit speculative rn in whether it actually achieves what you need/want in the second/third step. So I would like to see some proof (and docs) to show that. |
|
Luckily I did make a test repo of my experimentations 😉 https://github.com/lecrisut/attrs-playground |
does any of the examples use this? because the readme just says it's not supported. :) as said if this helps you with something concrete I'm open to it. long-term we should get rid of _CountingAttr, since it comes with a bunch of surprising behavior. Unfortunately, there's probably a non-trivial amount of software depending on it it, tho. So I wouldn't want to block you with that. |
Yeah, the readme is more intended for my colleagues. You can try out the example with and without the patch to see the difference. It is required, otherwise it would not detect the field 1 as a
Right now it is only this idea that would depend on it, so there is no immediate rush. If there are ideas of what can take its place, then I'm all up for pivoting the design. At the core of this I think the issue is that Footnotes |
|
No, I do not really have any ideas. I just want to get rid of the counting that we needed before Python 3.6. I'm mostly saying that I'm not married to anything about _CountingAttr. I guess your subclassing idea makes sense; the q is just what the new class should do except being public? |
2 participants
Summary
The main purpose for this is to allow custom fields to extend the field decorators. This does technically enable that by subclassing the private class and adding the appropriate methods as in #1543.
I do not believe this is the best approach for handling #1543, it's just the quickest way to unblock it. The class should probably become something more public. If there are other ideas happy to explore them.
Pull Request Check List
mainbranch..pyi).typing-examples/baseline.pyor, if necessary,typing-examples/mypy.py.attr/__init__.pyi, they've also been re-imported inattrs/__init__.pyi.docs/api.rstby hand.@attr.s()and@attrs.define()have to be added by hand too.versionadded,versionchanged, ordeprecateddirectives.The next version is the second number in the current release + 1.
The first number represents the current year.
So if the current version on PyPI is 26.2.0, the next version is gonna be 26.3.0.
If the next version is the first in the new year, it'll be 27.1.0.
.rstand.mdfiles is written using semantic newlines.changelog.d.